This commit cleans up setting enemy properties. It deduplicates code,
makes custom levels spawn enemies better (doesn't just pretend it's a
certain main game room to set the settings) and makes everything a nice
registry.

This is the basis of a future system which might allow for more enemy
types to be used in the editor, and even custom enemy types...

But it was mostly done for cleanup, since I hated how the code looked.

This should keep most of the mess outside of `setenemyroom`, however
`setenemy` still has a few variables I don't know how to tackle.

There's now variables in the struct to override certain properties.

Emitters are odd. They rely on `setenemy` to set the right type of the
entities they emit. However, `setenemy` only gets called in specific
rooms, so if you use these enemy types outside of those rooms, they'd
just infinitely spawn themselves and, well, that's a memory leak.

The prior fix for this was simply not allowing emitter types outside
of those rooms. This, however, feels very hacky and is a little
disappointing as well.

This commit improves emitters by no longer relying on `setenemy`, and
instead setting the emitted enemy type ourselves. However, `setenemy`
still happens, and to make sure we don't set the enemy type *twice*,
we set the `para` attribute of the spawned enemies to `-1`, so that
`setenemy` will not do anything at all to the spawned enemy.

The reason I don't remove the code in `setenemy` outright is a couple
things:

- The main game code still relies on it for spawning the initial
enemies in the room

- Custom levels may rely on the prior behavior (sadly)

There's a few cases in `setenemyroom` which are only meant to override
the enemy colour set in the type, so let's move that to it's own
function instead. While we're at it, we should move the custom level
enemy color logic there as well, because it's in an awkward place.

This will also help with things like custom enemy types in the future,
or using things like the emitters in custom levels, because this will
correct those colors in custom levels.

While the last commit was an attempt at making colors be set better,
this one should help more. Basically, things that emitters emit now
copy the emitter's color. That means, if you change the color of the
emitter, what it emits will change as well. This means we don't have
to worry about setting the colour ourselves, just the enemy type.

`set_enemy_colour` is now called BEFORE setting the type, so the type's
color will override the room color. This is what we want -- in the
future there might be custom enemy types, and if you specify a specific
color, you probably want that color to be used.

But wait, don't the types usable in levels have their colors set? Well,
this commit also duplicates the editor enemy types and sets their
colors to `-1` so they'll use the room's color instead, or more
accurately, they'll use the color they had previously, which was the
room's enemy color.

With this system, old levels which use main game enemies will have the
correct colors -- the colors stored in their enemy types. And if it
becomes possible to make custom enemy types, if someone makes an
emitter which uses the room's color (by passing in color `-1`), the
enemies which it emits will use the room's color as well, since it will
copy what the emitter itself uses.

All of that just to say: colors are now handled a bit more sanely.

So, the radar enemy type was originally 16x16. I meant to change it to
something that made more sense, but I messed up and made it 32x32
instead of 64x64 like it is visually.

This removes the magic numbers used for `animate`, and makes the
animation system far more flexible, instead giving entities the option
to control what they need, instead of having a bunch of duplicated
hardly-readable code.